feat(blobmanager/s3accesspoint): optional managed session policy via PolicyArns#3145
Conversation
…PolicyArns Add an optional Credentials.SessionPolicyARN field. When set, the per-request sts:AssumeRole call references a customer-managed IAM policy via PolicyArns instead of inlining a JSON policy document. Only the ARN counts against STS's packed-policy budget that way, leaving more headroom for session tags inherited from the caller principal (IRSA / Pod Identity). The field is optional and backwards-compatible: when empty, the backend continues to send the slim inline session policy. A missing ARN must NOT degrade to an unscoped session that inherits the full BaseRoleARN permissions, so the inline fallback is always present. Validation rejects values that are not IAM managed policy ARNs (e.g. S3 ARNs, role ARNs) at credential-load time rather than surfacing as opaque STS errors deep in the upload path. The sts.Client field on sessionCredentialsProvider is narrowed to a small stsAssumer interface so tests can lock down the AssumeRole call shape (inline Policy vs PolicyArns) without spinning up a real AWS config. No production behavior change. Assisted-by: Claude Signed-off-by: Jose I. Paris <jiparis@chainloop.dev> Chainloop-Trace-Sessions: ee4385fa-8011-4750-87cd-502097dda8b9
AI Session Analysis
|
| Status | Attribution | File | Lines |
|---|---|---|---|
| modified | ai | pkg/blobmanager/s3accesspoint/backend_test.go |
+80 / -0 |
| modified | ai | pkg/blobmanager/s3accesspoint/provider_test.go |
+52 / -0 |
| modified | ai | pkg/blobmanager/s3accesspoint/backend.go |
+35 / -14 |
| modified | ai | pkg/blobmanager/s3accesspoint/provider.go |
+37 / -5 |
Policies (4)
| Status | Policy | Material | Messages |
|---|---|---|---|
| ✅ Passed | ai-config-ai-agents-allowed |
ai-coding-session-ee4385 |
- |
| ✅ Passed | ai-config-no-dangerous-commands |
ai-coding-session-ee4385 |
- |
| ✅ Passed | ai-config-no-secrets |
ai-coding-session-ee4385 |
- |
| ✅ Passed | ai-config-mcp-servers-allowed |
ai-coding-session-ee4385 |
- |
Powered by Chainloop and Chainloop Trace
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 4 files
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
Replace the loose prefix-and-substring check with a proper arn.Parse plus service and resource-type assertions, so configuration mistakes that previously slipped through (role ARN whose path embeds ":policy/", policy ARN with an empty name, malformed ARNs) are now rejected at credential-load time instead of surfacing as opaque STS errors during upload. Adds AWS-managed-policy ARNs (arn:aws:iam::aws:policy/...) to the accepted set and locks down the previously-permissive shapes with table-driven test cases. Assisted-by: Claude Signed-off-by: Jose I. Paris <jiparis@chainloop.dev> Chainloop-Trace-Sessions: ee4385fa-8011-4750-87cd-502097dda8b9
2 participants
Summary
Adds an optional
Credentials.SessionPolicyARNto the S3-Access-Point CAS backend. When set, the per-requeststs:AssumeRolecall references a customer-managed IAM policy viaPolicyArnsinstead of inlining a JSON document. Only the ARN string is packed into STS's packed-policy budget that way, leaving more headroom for session tags inherited from the caller principal (IRSA / Pod Identity).BaseRoleARNpermissions.When the operator uses this path, the managed policy is the action allowlist for the session — chainloop no longer hard-caps actions inline. The policy MUST be at least as restrictive as the inline default (
s3:GetObject+s3:PutObjectscoped to\${apARN}/object/*). Cross-tenant isolation is unchanged: it lives in the AP resource policy'saws:useridcheck against the request-context-derived role session name.AI disclosure
Assisted by Claude (Anthropic).